Some software programs can exhibit programming errors or bugs, which can be difficult to identify with normal application testing. For example, employing a debugger can facilitate identifying many programming code errors. However, subtle errors, caused by heap corruptions, incorrect handle usage, critical section usage, etc., can escape detection. In addition, such errors can occur at locations remote from a root cause. For instance, a heap corruption can occur at a first point of program code, but not manifest (e.g., crash the program) until a second point of the program code executed later than the first point. An application verification tool can be employed to identify such errors.
Another class of programming errors includes concurrency bugs. Concurrency bugs arise from a concurrent nature of concurrent programs. A concurrent program includes one or more threads of control (hereinafter referred to as “threads”). The threads can relate to processes, threads within a process, processors in computer hardware, processing cores of a processor, and/or nodes in a distributed system. Concurrency bugs, in general, occur when instructions of a concurrent program execute or are scheduled to execute in an order not envisioned by a programmer. Accordingly, concurrency bugs can manifest on particular thread schedules among an exponential number of possible thread schedules. Concurrency testing typically involves identifying a buggy schedule in which concurrency bugs appear. One technique, to uncover concurrency bugs, is to stress test a concurrent program. Stress testing typically involves running the concurrent program for days, or even weeks, under heavy loads in the hope that thread schedule that uncovers a bug is discovered.
Concurrency bugs such as, but not limited to, ordering errors, atomicity violations, deadlocks, or the like, which are targets of conventional concurrency testing, are not the only bugs which can manifest in only a subset of possible thread schedules. For instance, memory corruptions, incorrect handle usages, critical section concerns, etc., can appear in particular thread schedules. The application verification tool can fail to detect errors tied to particular thread schedules without stress testing and, even with stress testing, inefficiently uncovers such errors.
The above-described deficiencies of today's application testing systems are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.